嗨大家好，我是Sean!
昨天講了一個常見的migration error也就是table already exists的情況。

今天再來講一個可能比較少見，但時間過久了，一定會碰到的情況?

Migration重製

昨天我們有說到，我們可以使用showmigrations來看我們目前遷移了哪些migraiton的檔案。
[Day 23] 激戰篇: 正面對決啊Migration error (上)

除此之外，若時間一久，我們的migraiton檔案多到不行，
我們想要刪除migration的檔案時，又該怎麼做呢?

如同我們昨天說的，如果直接刪除很有可能會有migration error的問題，我們必須把整個migration的紀錄重新才可以。
我們可以使用以下的指令來讓我們migration紀錄歸零:

python manage.py migrate --fake <your app name> zero

完成指令後，我們會得到以下的畫面。

可以看到下方的migration檔案已經unapplying，狀態是faked。
我們這時再用showmigrations看看完成的狀態。

python manage.py showmigrations

可以看到原本的三個migration檔案的狀態由 [x] 變為 [ ] 了，其原理其實就跟我們的fake很像，但就是反過來重製。

看到以上的畫面後，我們就可以放心的刪除所有migration的檔案以及pyc的暫存檔。
但是記得要留下__init__.py的檔案給系統辨識喔!

接下來，我們就重新做一次migration:

python manage.py makemigrations

接著我們要重新開始migration紀錄:

python manage.py migrate --fake-intial

我們這邊也是使用了fake，我們假裝initial這件事的發生，也就是我們其實沒有實際上創造這些model，僅僅是django_migration的表上添加紀錄，使的我們重製migration檔案的這件事發生。

好的這麼一來，我們的migration檔案就刪除到只剩一個了，但還保有完整的功能也不出錯!
那麼，今天的文章就到此結束，感謝大家的收看。

我是Sean，你各位海上的人，我們明天見!